home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
kermit.columbia.edu
/
kermit.columbia.edu.tar
/
kermit.columbia.edu
/
newsgroups
/
misc.20031118-20041115
/
000405_slash_dev_slas…_2000@yahoo.com_Fri Sep 24 17:36:20 2004.msg
< prev
next >
Wrap
Internet Message Format
|
2004-11-14
|
5KB
Path: newsmaster.cc.columbia.edu!newsfeed1.nycmny01.us.to.verio.net!newsfeed1.stngva01.us.to.verio.net!newspeer1.stngva01.us.to.verio.net!verio!news.tele.dk!news.tele.dk!small.news.tele.dk!news.glorb.com!postnews1.google.com!k26g2000oda.googlegroups.com!not-for-mail
From: "Mark Sapiro" <slash_dev_slash_null_2000@yahoo.com>
Newsgroups: comp.protocols.kermit.misc
Subject: Re: Return codes and If statments
Date: 24 Sep 2004 14:33:57 -0700
Organization: http://groups.google.com
Lines: 142
Message-ID: <1096061637.174541.255970@k26g2000oda.googlegroups.com>
References: <3f9c05b0.0409211252.5aa51cb1@posting.google.com>
<slrncl18i5.56s.fdc@sesame.cc.columbia.edu>
<1095827419.338981.28270@k26g2000oda.googlegroups.com>
<3f9c05b0.0409220853.25e5bd46@posting.google.com>
<slrncl3dp2.ftp.fdc@sesame.cc.columbia.edu>
NNTP-Posting-Host: 209.182.169.133
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Trace: posting.google.com 1096061637 23677 127.0.0.1 (24 Sep 2004 21:33:57 GMT)
X-Complaints-To: groups-abuse@google.com
NNTP-Posting-Date: Fri, 24 Sep 2004 21:33:57 +0000 (UTC)
In-Reply-To: <slrncl3dp2.ftp.fdc@sesame.cc.columbia.edu>
User-Agent: G2/0.2
Complaints-To: groups-abuse@google.com
Injection-Info: k26g2000oda.googlegroups.com; posting-host=209.182.169.133;
posting-account=iQNWIg0AAAAD2fStXNC9nwGlPdSqjWrI
Xref: newsmaster.cc.columbia.edu comp.protocols.kermit.misc:15183
Frank da Cruz wrote:
> On 2004-09-22, Peter V. <dm_v_2000@yahoo.com> wrote:
> : thank you both for your advice. I am sticking to recommended
format
> : Number 2, and that seems to have done the trick.
> :
> I realize it might be a big counterintuitive for C programmers, but
it
> should be recalled that Kermit differs from C not only in being
interpretive
> rather than compiled, but also it's an interactive command language,
and
> therefore necessarily line-oriented: each command is one line. Thus
the
> true format of a compound IF-ELSE statement is:
>
> if <condition> { command, command, ... } ELSE { command, command,
... }
>
> Prior to C-Kermit 7.0, if you wanted to break such a statement onto
multiple
> lines, you had to use line continuation:
>
> if <condition> { -
> command, -
> command, -
> ... -
> } ELSE {
> command, -
> command, -
> ... -
> }
>
> Version 7.0 added several tricks to the parser to give more natural
> syntax: (a) If a line ENDS with "{" (ignoring whitespace) it is
continued
> and begins a block; (b) if a line BEGINS with "}" (ignoring
whitespace) it
> ends a block; (c) if a block is active, the end of each line implies
a
> comma (which is used to separate statements within blocks). Once a
block
> is opened at top level, these tricks are used until the block is
closed,
> and naturally, they persist through any level of nesting. This
explains
> why a construction like:
>
> IF <condition> {
> command
> command
> }
>
> works, but:
>
> IF <condition>
> {
> command
> command
> }
>
> doesn't. The first line is an incomplete command with no indication
of
> continuation. The documentation:
>
> http://www.columbia.edu/kermit/ckermit70.html#x7.20
>
> does not list the latter form as a possibility.
That is true, but that was not my point in my prior post in this
thread. My point is that ever since 8.0.206. The forms of examples 3
and 4 in the referenced documentation do not always produce the same
results as the forms of examples 1 and 2.
In particular, consider example 2 - the preferred form
IF condition {
command1
command2
} ELSE {
command3
command4
}
vs. Example 3 (same as 1 and 2):
IF condition {
command1
command2
}
ELSE { command3, command4 }
and Example 4 (same as 1-3):
IF condition {
command1
command2
}
ELSE {
command3
command4
}
As far as I can tell, example 2 always works as expected, but in the
case where condition is False and command3 and or command 4 contains a
Macro reference, the macro reference will not be expanded in example 3
and 4 as it is in example 2.
This is illustrated by the following:
# Example 2 (same as Example 1):
IF false {
.theday := \v(day)
show macro theday
} ELSE {
.thedate := \v(date)
show macro thedate
}
# Example 3 (same as 1 and 2):
IF false {
.theday := \v(day)
show macro theday
}
ELSE { .thedate := \v(date), show macro thedate }
If this is run today, example 2 will output
thedate = 24 Sep 2004
but example 3 will output
thedate = \v(date)
This behavior was introduced by changes in the way immediate macro's
are handled in ckuusr.c, 23 Aug 2002.
These changes were intended to solve a problem that might more properly
have been addressed by escapes in the command.